-
Notifications
You must be signed in to change notification settings - Fork 451
[cisco_ios] Fix parsing of hostnames that start with a digit #13816
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices) |
packages/cisco_ios/data_stream/log/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a sample event that we can use as a test? Would like to see this in action.
The test in |
So re-generating
(I deleted the expected file and re-generated it, since Note the year. Unfortunately, this change is handling the year incorrectly (or not at all). |
🚀 Benchmarks reportTo see the full report comment with |
💚 Build Succeeded
History
cc @ilyannn |
|
Proposed commit message
This PR improves the Cisco IOS ingest pipeline to properly handle hostnames that begin with digits. Even though such hostnames do not strictly conform to the Cisco IOS naming specification, hostnames starting with digits are commonly used in real-world configurations.
To do this we modified the grok pattern to allow such hostnames, e.g.
Due to the limitations of the grok parser's regex support, this also allowed all-digit hostnames, which caught cases like
where
2361044
is in the same place as the hostname but is instead a sequence number (compare). We had to special-case this processing with additional ingest processors.
Another problem was created by timestamps like this
where
2023
is in fact part of the timestamp but2023host
is a valid hostname (and the timestamp does not contain the year at all). We fixed this issue by making sure that there is an additional attempt to recognize the timestamp pattern before proceeding with recognizing it as a hostname.These cases are covered by new tests in
test-numeric-hostname.log
. Note that@timestamp
is a dynamic field (the timestamp without a year refers to a current year), so correctness of some tests is not checked automatically.Checklist
changelog.yml
file.